Traditionally, automated testing of loaded printed circuit boards (PCB's) involved functional test wherein input signals were provided to the external inputs of a PCB and output signals were observed from the external outputs of the PCB. This type of functional testing, however, can become very complicated for complex circuitry and can provide only limited diagnostics. Modern testing increasingly supplements this traditional functional test with the efficient, flexible in-circuit test. In-circuit test is a type of functional test wherein the performance of each device (e.g., a digital integrated circuit) on a PCB is independently tested as a functional unit.
In-circuit testing is described in detail in U.S. Pat. No. 5,004,978, entitled "METHOD FOR REGENERATING IN-CIRCUIT TEST SEQUENCES FOR CIRCUIT BOARD COMPONENTS", which is incorporated herein by reference.
In order to perform in-circuit test, a tester must apply input signals directly to the inputs of a DUT (device under test) and must access the outputs of the DUT to observe the output response. A "bed-of-nails" (i.e., probes that directly make contact with the device I/O pins from pads on the surface of the PCB) fixture is used to provide access to the required nodes on the PCB. Each device can then be tested as if it were electrically isolated from the circuit.
A principal advantage of in-circuit testing is that tests for many common IC's (integrated circuits) can be programmed once, in advance, and then stored in a library. The tests can then be called upon when needed. This greatly simplifies test generation since this pre-programmed test can be used over and over again.
In-circuit testing is conventionally performed on an ATE (Automated Test Equipment) system. An ATE system (tester) 100 is shown in FIG. 1. ATE system 100 includes a test generator 102 and a test controller 104. Test generator 102 generates an in-circuit test for each device on the PCB under test. A generic test plan 106 provides supervisory control over testing. This includes sequencing the tests, logging the results, controlling PCB/fixture interfacing, controlling the test power supplies, and providing a user interface.
The combination of the individual in-circuit tests and test plan 106 forms a PCB test specification. A device models library 108, physical database 110, and an electrical database 112 provide the data required for test generator 102 to generate the individual in-circuit tests. Electrical database 112 contains a list of the electrical devices on the PCB, an electrical description for each device, electrical interconnect information, a list of the devices to be tested, and test requirements for each device (e.g., required power supply voltages and test probe requirements). For the HP3070 tester (described below), the electrical data is stored in the "BOARD" file. Physical database 110 contains a topological description of the PCB which will be used by test controller 104 to locate and test each DUT 116. Physical database 110 also contains user-defined information, such as node accessibility.
Physical database 110 and electrical database 112 are typically generated by a CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) system during design of a PCB.
Device models library 108 contains a plurality of pre-generated generic models for commonly used digital integrated circuit chips (IC's). Essentially, each model is a test routine which may be inserted (i.e., edited) into the PCB test specification. Each device model provides, for a specific device: pin-out information (i.e., which pins are inputs, outputs, bi-directional, or unused), trace data (i.e., information which relates each device output to the device inputs which affect it), a test routine, a method for pre-conditioning each output of the device, and device specific information including a test pattern rate and required signal levels. When devices which are not represented in device models library 108 are encountered, a model may be manually entered into the tester and, if desired, the models library.
Test controller 104 executes the in-circuit tests generated by test generator 102. A driver module 114 is used to apply the test signals to a DUT 116, and a sensor (receiver) module 118 is used to receive the response of DUT 116 to the test signals. The combination of driver module 114 and sensor module 118 is known as a tester channel.
The HP3070 programmable in-circuit tester is an example of an ATE system. The HP3070 tester is manufactured by Hewlett-Packard Company, Palo Alto, Calif. Detailed operational information for the HP3070 is contained in "HP3070 Board Test System User's Documentation Set (1989)" available from Hewlett-Packard under HP part number 44930A.
While in-circuit test provides a thorough test mechanism, the test can become lengthy since each component is tested independently. In addition, certain devices may not be independently testable due to node accessibility problems, special signal requirements, or device complexity. The node accessibility problem is exacerbated by increasing circuit miniaturization and complexity (e.g., surface mount devices, multi-chip modules, ASIC's, etcetera).
A sample circuit 200 illustrating these problems is shown in FIG. 2. Circuit 200 includes an oscillator U1, a NAND gate U2, an inverter U3, and a buffer U4. The output (pin U1-1) of oscillator U1 is tied to an input (pin U2-2) of NAND U2. The other input (pin U2-1) of NAND U2 is connected to the logic supply voltage V.sub.CC through a resistor R1. The output (pin U2-3) of NAND U2 is connected to the input of inverter U3 (pin U3-1). The output of inverter U3 (pin U3-2) is connected to the input of buffer U4 (pin U4-1).
In attempting to test circuit 200, any number of problems can occur. For example, the oscillator signal from oscillator U1 may interfere with testing of downstream devices U2-U4. The conventional in-circuit method would test U2 by driving pins U2-1 and U2-2 and then inspecting pin U2-3 for the proper response. Driving pin U2-2, however, requires backdriving the output (pin U1-1) of U1. U1-1 is an oscillator output which cannot be reliably backdriven. Therefore, U2 cannot be tested. Further, the oscillator signal from U1 will be propagated downstream through U2 to U3 and U4 (and beyond), interfering with testing of these downstream devices. Thus, it is desirable to disable U1. U1, however, does not have a disable feature.
A common solution to this problem is to "group" or "cluster" U1 and U2 together and to test the pair as a functional unit or cluster 202. Cluster 202 functionally represents an oscillator with a disable feature. That is, if pin U2-1, is pulled LOW by a probe of the tester, then pin U2-3 will always be HIGH (due to the logical NAND function of U2). This prevents the oscillator signal from U1 from propagating through U2 so that it appears that U1 has been disabled with respect to U3 and U4. This benefits the testing of all downstream components. Further, both U1 and U2 and the interconnection between them may be tested at the same time.
Another problem which can occur during testing of circuit 200 is that of inaccessible pins. For example, pins U3-2 and U4-1 may be unavailable at the surface of the PCB so that both U3 and U4 cannot be tested. Clustering there two devices together into a cluster 204, however, will allow testing of both devices together as a single functional block. This obviates the need to access pins U3-2 and U4-1.
In addition to solving test access problems, clustering can be used to simplify and speed the in-circuit test by dividing a complex circuit into a relatively small number of testable clusters. Each cluster can then be tested to provide a pass/fail indicator of device performance. This actually results in a better indication of device function than in-circuit test on a device by device basis because the interrelation between the components is also tested. Further, the in-circuit test is shortened because many components are tested together rather than separately.
Conventionally, in-circuit tests have been used to test as many components as possible with cluster testing being performed only if a device was not testable due to one of the above-described problems. The conventional method for generating an in-circuit test is shown in FIG. 3. At step 302, an electrical description of the PCB from electrical database 112 is analyzed to determine which devices require testing. At step 314, a generic device model for each DUA (device under analysis) is retrieved from device models library 108. As discussed above, each device model contains a complete test routine for the particular device. This includes the details necessary to instruct test controller 104 how to test the DUA.
If, at step 316, a device model for a DUA is not present in device models library 108, then a device model is written for the DUA at step 318. Device models are manually written by the test programmer. Once the device model is written, it may be added to device models library 108.
After a device model has been retrieved for as many devices as possible, the test programmer analyzes the PCB to identify any devices which require clustering and then defines the clusters at step 320. A cluster model (i.e., test routine) is then written by the programmer and manually entered into the ATE system. Practically speaking, few (if any) clusters are actually defined this early in the test method due to the complexity of the circuits being tested and the difficulty in anticipating problems. More frequently, clusters are defined during execution of the in-circuit test (step 332) to remedy a problem incurred in testing a particular device.
At step 322, the test-specific electrical description for the PCB under test is produced. That is, the device models retrieved at step 314, the device models written at step 314, and any cluster models written at step 320 are used to customize the electrical description of the PCB for the particular test being generated. The test-specific electrical descriptions for two identical PCB's may differ depending on factors such as the clustering methodology and the type of test fixture used.
At step 324, the test-specific electrical description from step 322 for the PCB under test along with physical data from physical database 110 is used to generate test fixture description 326 and test source data 328. Test fixture description 326 represents the data required to generate the test fixture which interfaces the PCB under test with the ATE system. Test source data 328 includes the digital test patterns from the device and cluster models which have been adapted to the particular PCB under test. Adapting (or editing) involves removing conflicting test patterns and adding conditioning and disabling statements.
Finally, at step 330, test source data 328 and fixture description 326 are debugged, and modified for any problems not foreseen during test generation to produce a completed in-circuit test 332. It is at this debugging step that the majority of clustering normally occurs. Unfortunately, the test fixture is often built by this time such that modification might be necessary to accommodate testing of the clusters. Modifications to the test fixture are expensive and increase the time-to-production-release (i.e., production time loss), which is a critical profitability factor in manufacturing.
This conventional method has the additional weakness that cluster identification and definition must be performed by the test programmer who must analyze the circuit schematics based on his or her engineering judgment and experience. This method is time-consuming, prone to errors, and requires experience which is not readily available throughout the industry.
What is needed is a method which will automatically identify devices within an electronic circuit which may/must be tested together as a cluster and then retrieving, for each cluster, a pre-defined test pattern from a library.